1. Technical Field
This invention relates generally to mobile cellular telecommunications, and more particularly, to a method of utilizing existing signaling protocols, such as the American National Standards Institute (ANSI)-41 protocol, to implement more efficient handoff back operations.
2. History of Related Art
Within a telecommunications network that supports Mobile Station (MS) movement, several methods have been devised to transfer communications for active call connections maintained by any one MS as it moves away from one serving switch toward another. The ANSI-41D Standard includes several procedures and messages to implement such inter-system (inter-exchange) handoff forward operations (i.e., transferring the active call connection of a MS from the serving switch to a target switch which is not currently trunk-connected in the call), and handoff back operations (i.e., transferring the active call connection from the serving switch to a target switch which is already trunk-connected within the call path). While several scenarios are offered for conducting handoff forward operations with a tandem switch, only two scenarios are available when a handoff back operation must be accomplished. Further, the handoff back call connection operation is only valid for use when the target switch is connected directly to the serving switch (i.e., there is a direct trunk connection therebetween). Thus, for example, the handoff back message cannot be used to transfer a call connection directly from a serving Mobile Switching Center (MSC) to an anchor MSC using the anchor MSC as the target switch if there is a tandem MSC located along the call path between the anchor MSC and the serving MSC.
While it is possible to invoke the handoff back operation under such circumstances (i.e., where multiple switches are trunk-connected along a call path, and the target switch is not immediately trunk-connectable to the serving switch), the result may be that trunks between the various switches (connected before handoff) will not be released after the handoff operation occurs. Thus, network resources are wasted.
Another problem occurs when a HandoffToThird message (used as an alternative to the handoff back message) is received by a tandem switch which does not support a handoff operation with path minimization. The result is a RETURN ERROR or REJECT response sent back to the requesting switch. Alternatively, no response at all may be received by the requesting switch. When this occurs, the serving switch must send a FacilitiesDirective message back along the call path, past the tandem switch, so that the handoff can occur. However, once again, previously connected trunks along the call path may not be released, and network resources will be wasted.
These scenarios are illustrated in FIGS. 1, 2, 3, and 4. FIG. 1 is a network signaling and nodal operation diagram illustrating basic prior art handoff back operations, wherein the telecommunications network 10 includes a telephone 40, an anchor MSC 60, a tandem1 MSC 70, a tandem2 MSC 80, a serving MSC 90, and a MS 50. There is an active call connection between the telephone 40 and MS 50, using a series of switches 100, which are connected by trunks 120, 130, and 135. The telephone 40 (which may be a wireline telephone or another MS) is connected to the switches by way of a residential line connection or wireless network interface 110, and the MS 50 is connected to the serving MSC using a wireless network interface 140.
If the serving MSC 90 operates to determine that a handoff operation to an adjacent candidate MSC, such as the tandem2 MSC 80, is appropriate, the serving MSC 90 sends a HandoffMeasurementRequest message 150 to the tandem2 MSC 80. In response, the candidate MSC 80 performs location measurements according to its internal programming algorithms, and returns the results to the serving MSC 90 in the form of a HandoffMeasurementRequest response 160. Based on the response 160 content, the serving MSC 90 determines that the call should be handed off to the tandem2 MSC 80, which is now also considered the target MSC 80. In this illustration, the serving MSC 90 has also determined that the tandem2 MSC 80 is already trunk-connected along the call path.
At this point, a HandoffBack message 163 is sent from the serving MSC 90 to the target MSC 80, which directs the target MSC 80 to initiate a handoff back task. If a voice channel on the target MSC 80 is available, a HandoffBack response 167 is returned to the serving MSC 90, which allows the handoff operation to proceed.
The serving MSC 90, upon receipt of the HandoffBack response 167, sends a Handoff Order message 190 to the served MS 50. This action directs the MS 50 to move to the available voice channel on the target MSC 80. Upon arrival 200 of the MS 50 on the voice channel of the target MSC 80, a FacilitiesRelease message 202 is sent from the target MSC 80 to the serving MSC 90. This indicates that the handoff operation has been successful and that the facilities used by the serving MSC 90 are no longer needed. The serving MSC 90, in turn, sends a FacilitiesRelease response 204 to the target MSC 80, releasing the trunk connection 135 and marking the inter-MSC trunk 135 as idle. The target MSC 80, in turn, marks the inter-MSC trunk 135 as idle and the handoff back process is complete. The resulting call connection between the telephone 40 and the MS 50 comprises the series of switches 100 connected by trunks 120 and 130. The telephone 40 is connected to the Anchor MSC 60 by way of line connection or wireless interface 110, and the MS 50 is connected to the new serving MSC 80 using the wireless network interface 137.
The scenario 20 just described, is a classic prior art handoff back operation from a serving switch 90 to a tandem switch 80, where the tandem switch 80 is trunk-connected to the serving switch 90 along the call path. In this scenario, the handoff back operation is directed toward the tandem2 MSC 80. However, the command operates in exactly the same manner if the Anchor MSC 60 is physically located in the place of the tandem2 MSC 80, such that the target switch 100 is the Anchor MSC 60, instead of the tandem2 MSC 80. As long as the handoff back is made to the immediately previous switch in the call path, no network resources are wasted, and the ANSI-41 protocol operation functions in an efficient manner.
A successful sequence of handoff operations in the prior art can also be seen in the network signaling and nodal operation diagram of FIG. 2. In this case, a successful handoff back with tandem using the HandoffToThird message and path minimization are shown within a telecommunications network 15 including a telephone 40, an anchor MSC 60, a tandem MSC 70, a serving MSC 90, and a MS 50 are shown. There is an active call connection between the telephone 40 and MS 50, using switches 60, 70, and 90, which are connected by trunks 120 and 130. The telephone 40 (which may be a wireline telephone or another MS) is connected to the switches 60, 70, and 90 by way of a residential line connection or wireless network interface 110, and the MS 50 is connected to the serving MSC using a wireless network interface 140.
If the serving MSC 90 operates to determine that a handoff operation to a nearby candidate MSC, such as the anchor MSC 60, is appropriate, the serving MSC 90 may send a HandoffMeasurementRequest message 150 to the anchor MSC 60. In response, the anchor MSC 60 performs location measurements according to its internal programming algorithms, and returns the results to the serving MSC 90 in the form of a HandoffMeasurementRequest response 160. Based on the response 160 content, the serving MSC 90 determines that the call should be handed off to the anchor MSC 60, which is now also considered the target MSC 60. The anchor MSC 60 will be directed to receive the MS 50 using the handoff back call connection with path minimization operation, and the MS 50 will be moved to the designated channel 107 of the anchor MSC 60. Directing the anchor MSC 60 to receive the MS 50 involves sending a HandoffToThird message 290 from the serving MSC 90 to the tandem MSC 70, which in turn directs the tandem MSC 70 to perform an intersystem handoff task with path minimization; sending a HandoffToThird message 320 from the tandem MSC 70 to the anchor MSC 60, which results in directing the anchor MSC 60 to perform path minimization and verifies that the designated channel 107 of the anchor MSC 60 is available to support the MS 50; and sending a HandoffToThird response along the call path from the anchor MSC 60 to the serving MSC 90 (steps 330 and 340).
Moving the MS 50 to the designated channel 107 of the anchor MSC 60 requires sending a Mobile Handoff Order 190 from the serving MSC 90 to the MS 50 and receiving the MS 50 on the designated channel 107 at arrival step 200. Directing the tandem MSC 70 and serving MSC 90 to release the first and second inter-MSC trunks 120 and 130, and marking the first and second inter-MSC trunks 120 and 130 as idle requires sending a FacilitiesRelease message along the call path from the anchor MSC 60 to the serving MSC 90 (i.e., steps 220 and 230), sending a FacilitiesRelease response 260 along the call path from the serving MSC 90 to the tandem MSC 70, and sending a FacilitiesRelease response 270 along the call path from the tandem MSC 70 to the anchor MSC 60.
At this point, the call path between the telephone 40 and the MS 50. includes only the telephone line or wireless network interface 110, the anchor MSC 60, and the wireless network interface 280 No unused inter-MSC trunks 120, 130 are left connected, and network resources are conserved. However, as noted above, the intersystem handoff task can not be accomplished by simply sending a handoff back or HandoffToThird message directly from the serving MSC 90 to the Anchor MSC 60, which is also the Target MSC 60. This is because the MSCID (MSC IDentification number) for the Anchor MSC 60 is only known to the Tandem MSC 70, and not to the Serving MSC 90. Conventional ANSI-41D protocol operations do not explicitly forward the MSCID parameter for all of the switches in a call path, but only for that switch that hands a call connection forward to another switch (to be connected) in the call path. Thus, each switch connected in a call path is only able to reference the MSCID for the immediately previous, and immediately following, switch in the path.
Turning now to scenario 30 of FIG. 3, the prior art handoff back operation to a switch 100 (i.e., anchor MSC 70) which is in the call path, but is not directly trunk-connected to the serving MSC 90 and does not support path minimization, is illustrated. In this case, as will be described, a handoff back operation using the Facilities Directive message results in a lengthy series of message transactions, wasting network resources.
In this case, an active call connection between the telephone 40 and the Mobile Station 50 exists, making use of trunk connections 130 and 135. A HandoffMeasurementRequest message 150 is sent from the serving MSC 90 to the Anchor MSC 70. The HandoffMeasurementRequest response 160 is returned to the serving MSC 90, where it is determined that a handoff back operation from the serving MSC 90 to the Target MSC 70, which is also the Anchor MSC 70, is desirable.
A FacilitiesDirective message 165 is then sent from the serving MSC 90 to the Anchor MSC 70, which results in a FacilitiesDirective response 169 from the Anchor MSC 70 to the serving MSC 90. The Handoff Order 190 is sent to MS 50, and the MS 50 arrives 200 on the available channel of the Anchor MSC 70. The Anchor MSC 70 sends a Mobile Station On Channel message 206 to the initiator of the handoff back task (i.e., the serving MSC 90), informing the serving MSC 90 that the Anchor MSC 70 has completed the handoff back task. Unfortunately, at this point, all of the trunks 130 and 135 are still connected. Moreover, a new trunk 138 has also been connected between the Anchor MSC 70 and the serving MSC 90. The resulting call connection between the telephone 40 and the MS 50 now comprises the series of switches 100 connected by trunks 130 and 135. The telephone 40 is connected to the switches 100 by way of line connection or wireless interface 110, and the MS 50 is connected to the new serving MSC 70 using the wireless network interface 139. The FacilitiesRelease messages 141,142, and 143 are used in the conventional fashion, along with the FacilitiesRelease responses 144, 145, and 146 to release trunks 130, 135, and 138, which are no longer necessary to maintaining the call path connection between the telephone 40 and the MS 50.
Referring now to FIG. 4, scenario 35 illustrates what can happen in prior art communications when a HandoffToThird message is sent to a switch which is incapable of accepting the HandoffToThird message for execution. The same result may occur if no response is received to the message due to congestion within the network 15, or for other reasons recognized by those skilled in the art.
In this case, a HandoffMeasurementRequest message 150 is sent from the serving MSC 90 to the Anchor MSC 70 (which is also the desired target switch 70), which elicits a HandoffMeasurementRequest response 160 from the Anchor MSC 70 to the serving MSC 90. The serving MSC 90, in turn, sends a HandoffToThird message 290 to the tandem MSC 80, which is incapable of processing the message 290. As noted above, there may be no response because the tandem MSC 80 does not support the HandoffToThird command, or possibly, because the network 15 is congested. In any event, an error 300 occurs, and the serving MSC 90 receives a response such as RETURN ERROR, REJECT, or no response at all is received (i.e., xe2x80x9cNO RESPONSExe2x80x9d means that there is no response and the serving MSC 90 times out).
Since the tandem MSC 80 is incapable of supporting a handoff operation with path minimization (as evidenced by the error message), a FacilitiesDirective message 165 is instead sent from the serving MSC 90 to the Anchor MSC 70, or target MSC 70. Once the Anchor MSC 70 verifies that a designated channel is available for use by the MS 50, a FacilitiesDirective response 169 is sent from the Anchor MSC 70 to the serving MSC 90. This results in a Handoff Order message 190 being sent from the serving MSC 90 to the MS 50 directing movement of the MS 50 onto the designated channel at the target MSC 70. After arrival 200 of the MS 50 on the designated channel at the target MSC 70, the target MSC 70 will send a Mobile Station On Channel message 206 to the serving MSC 90. At this point, the conventional series of FacilitiesRelease messages and facilitiesrelease responses 141-146 are used to release the trunks 130, 135, and 138, from the call path, as they are no longer needed to support communication between the telephone 40 and the MS 50 (now connected by the line connection/interface 110 and the network interface 139. This lengthy series of message interchanges, also required for the scenario described in FIG. 3, is inefficient, and wastes network resources.
Therefore, what is needed is a method to support a handoff back call connection operation within a telecommunications network, including multiple, connected switches, that enables the release of unused trunks along the call path when the target switch is already active within the call path, and not directly connected to the serving switch. This method would be especially useful if the MSCID of an Anchor MSC was made known to the serving MSC prior to initiating handoff operations, so that the served MS could be handed back directly to the Anchor MSC, when the Anchor MSC is also the target MSC. Such a method should be usable within the current ANSI-41D Standard, and also be backward-compatible with previous versions of the standard. Such a method should require no changes in currently-available network switch hardware.
The method of the present invention operates to enable handoff back operations within a telecommunications network during several different call connection scenarios, with the condition that the target MSC is the same switch as the Anchor MSC. First, when path minimization is possible and the handoff occurs between a serving switch and a target (Anchor) switch, wherein the target switch is already connected within the call path, and is not directly trunk-connected to the serving switch. Second, where call path minimization may be possible, but it is determined that one of the switches in the call path does not support path minimization operations. Finally, when path minimization is not possible, and the handoff occurs between the serving switch and the target switch, as described in the first scenario. In each case, the target MSC is a switch in the call path that has no direct trunk connections to the switch currently serving the MS, and wherein the target MSC is also the Anchor MSC to which the call connection is being handed off.
The method of the present invention makes use of the MSCID for the Anchor MSC contained within the BillingID of a FacilitiesDirective message that the serving MSC receives from the immediately preceding MSC in the call path (i.e., which can be an Anchor MSC, or some other tandem MSC). Since the MSCID for the Anchor (hereinafter the xe2x80x9cMSCID-Anchorxe2x80x9d) is known by the serving MSC, a handoff back operation can be made directly from the serving MSC to the Anchor MSC using the MSCID-Anchor embedded within a conventional ANSI-41 Mobile Application Part (MAP) operation.
The method of the present invention has at least two advantages: first, there are no trunks which must be connected to effect the handoff operation, and second, the standard ANSI-41D handoff back operation may be used with increased utility for this purpose. No change in the method of using the standard handoff back operation is required. Using this method, all of the intervening tandem MSCs in the call path are bypassed, and released in the conventional manner. Essentially, the handoff back operation is forced to operate with the final destination of the call, which turns out to be the Anchor/Target MSC. Since the handoff is made directly back to the Anchor MSC, it is immaterial whether intervening tandem MSCs are able to recognize the handoff back command, or whether path minimization is supported throughout the call path.